They are also used for GCD and LCM in France.

like xor with plus.circle

Wouldn't that be like plus.circle for xor?

I took the names from LaTeX, though I'm not too happy about "vee".

We already have ell for ℓ, and are considering adding pee for ℘. With this in mind, I agree vee is not a very good name because I would expect it to be a somewhat rounded "v."

+1.

They are also more generally used for meets and joins in a lattice (related to the order theory example given by @T0mstone).

Also agree that vee is unsatisfying, but I don't have any suggestions at the moment.

@T0mstone note that you would also need to add sect.wedge for sect.and, and union.vee for union.or.

Also agree that vee is unsatisfying, but I don't have any suggestions at the moment.

To be fair, I don't really like wedge either (although this is more a matter of taste). But at least it probably cannot be confused with anything else, and is well known by people coming from LaTeX.

An alternative to vee that I don't really like, but feels worth mentioning, is wedge.inv. Or wedge.t and wedge.b, with wedge.t being the default.

At first glance, I'm not a big fan of this. Let's discuss it more before any merge. (Next week.)

I've added sect.wedge and union.vee for now.

As for the discussion, I personally think this is a very reasonable request and if we don't have this, then we should take away xor, which I judge as about the same level of niche as the applications mentioned above.

What I mainly dislike about this is the following: For the meaning of "and" and "or", and and or are, in my opinion, much better than wedge and vee. However, by introducing these two aliases, people coming from LaTeX will just stay with wedge and vee because it's what they are used to. In an attempt of making math markup more semantically correct, we'd likely reduce the average semantic correctness of documents in the wild. This is of course a more general problem, but it's especially pronounced here.

People that use these operators for other meanings than "and" and "or" should probably define their own binding. I can agree that defining let meet = sym.and is a bit less clean than let meet = sym.wedge (though there's always let meet = "\u{2227}"), but I'm not sure that outweighs the downside of hurting the visibility of and and or.

I agree with @laurmaedje's point.

However, the use of these symbols for meets and joins are also exceptionally common, so I'm inclined to say that we should perhaps also have them as meet and join -- in fact, these terms subsume their use in logic (and can be seen as a meet, and or can be seen as a join).

I'm unfamiliar with the original motivating example of exterior and regressive products, but a quick search seems to reveal that they are also special cases of meets and joins in the sense of lattices (and are even sometimes called meet and join). So I think my current vote right now is to just also include these as meet and join, and avoid 'non-descriptive' and LaTeX names (though wedge does actually seem to be occasionally used in geometric algebra).

If "people coming from LaTeX" is the issue, how about just using different names? Then, if people ask, we can direct them to and and or first.

For example, they could be angle.t and angle.b.

Edit: Didn't see @dccsillag's point above before writing this. I'd also be fine with meet and join.

There is a problem because join already exists as ⨝

Some more context about the current join symbol and bowties, from the Symbol Proposals document.

In summary, the difference between bowties and the current join symbol is the math class, and (roughly) there is not enough symbols in Unicode for it to make sense to have two different symbols (bowtie and join) with their variants. If we really want to use join for the logical or symbol, the current join could be renamed to bowtie.big.

As far as I'm aware, meets and joins are way more common than bowties, and more commonly referred to as simply 'join'. So my personal vote is to change join, and have the bowtie as bowtie or similar (possibly also accessible with a dot under join, e.g. join.nat [for 'natural join'], but I don't think this is crucial).

Converting this to a draft since it would ideally be done with the changes from #27 instead.

With #93 now merged, the name "join" will be unblocked after the next release, so I've made the name change here and will mark it ready to review.
(Also adding "blocked" as it's blocked until the next release)

I'm unfamiliar with the original motivating example of exterior and regressive products, but a quick search seems to reveal that they are also special cases of meets and joins in the sense of lattices (and are even sometimes called meet and join).

I've never heard of meet and join before, but according to Wikipedia, the wedge shaped one of them is commutative and that's not the case for the exterior product, so it can't be a special case of it. So if we are adding an alias for the special meanings meet and join, I think we should handle the exterior/wedge/Graßmann product and the symmetric and regressive products as well.

Well, the exterior product is anticommutative, so its "absolute value" (if you want to define such a thing) would be commutative, which I would consider close enough.

Anticommutative is literally the opposite of commutative. So my point is, that this prevents the exterior product to be a special case of meet and join so we don't even need to argue in what sense it could be one.

Also meet and join feel a bit obscure to me. There are no German/French/Italian/… Wikipedia articles for it and I haven't encountered these terms and associated symbols even once in my Math Bachelor and Master studies.

Anticommutative is literally the opposite of commutative.

Only in name, I'd say the opposite of commutative is noncommutative. Anticommutative is very similar to commutative, it just has an extra minus sign. But you're right that it's not strictly a special case then.

Also meet and join feel a bit obscure to me.

Sure, that's a valid argument. I'm not just trying to push these terms either. However they are the best among those considered so far imo (see the criticism of vee above).

As a new idea, maybe we could also call them wedge and wedge.inv? Tho the asymmetry there also bugs me a bit.

Also meet and join feel a bit obscure to me.

I think this summarizes my current thoughts on this change. Yes, and and or are specific and do not match every use of those symbols, but I never heard of meet and join and those symbols are also used for things that don't even correspond to the notions of meets and joins, such as GCD and LCM (in French at least). If someone uses those symbols for something other than logical conjunction and disjunction, they can always create their own names in Typst.

As a new idea, maybe we could also call them wedge and wedge.inv? Tho the asymmetry there also bugs me a bit.

If we add descriptive names for those symbols, I think wedge is definitely the way to go. But in that case, I would even consider adding < and > as wedge.l and wedge.r.

such as GCD and LCM (in French at least)

GCD and LCM are instances of meet and join fwiw.

Since the wedge product is way more common than the products denoted by the inverse wedge, I think wedge and wedge.inv would be ok from a geometry point of view.

I'm still quite strongly against adding wedge and/or vee (see #26 (comment)). I'd rather add nothing at all then.